Crafting an automation strategy that gives back
A comprehensive collection of articles, videos and more, hand-picked by our editors
The only thing worse than not automating is trying to automate too much.
IT automation and orchestration have been popular for a while, and the reason is simple: Why do the same thing repeatedly when you can have a script do it for you? But, it's important to remember that IT automation may not be for everyone, and deciding what and how much to automate can be difficult. The problem is that it takes effort to automate processes, and you simply may not see the benefit from the effort. Automation in an enterprise...
environment is seldom a set-and-forget matter; automation needs maintenance.
Determining how heavily to rely on automation really depends on your scale. Automation makes more sense at a larger scale, so how much you automate will depend on how big your business plans to get.
Limit IT automation in small and medium-sized businesses
If you are a small business and plan to never have more than five VMs, then there is little point to automating anything. You won't be building enough hosts or VMs for the effort to pay off. Make sure to document the steps as you build the hosts and VMs. That way, you can consistently repeat the process with confidence. On the other hand, even with one host and five VMs, there are routine checks that can be easy to forget, since you have a lot of other things to manage. You may choose to automate the routine checks, backups and updates so they actually happen. Remember to check the outputs of the scripts and update the scripts as your environment changes. For example, free disk space thresholds should be very different when you change to using thin provisioning of VMs or LUNs.
If your business is a little bigger and has 50 to 100 VMs, then you probably want to use some sort of VM build automation, templates or automated operating system deployment. Now, it is worth investing in guest OS build automation, and the earlier you invest in this automation, the sooner you get benefits. Adding automation when you're halfway into production deployment will be much harder than getting it in place from the start. The payoff is biggest if every VM is built using the same automation, since this will make it easier to automate management later. At this scale, you probably have only a few virtualization hosts, so you can build each one manually by following a well-documented process. Automated checks and backups will really pay off here, since manual health checks on 100 VMs would take someone all day -- meaning it is likely to be put off.
Larger businesses see larger returns
VM build automation will really pay off for an environment with hundreds of VMs. At this scale, an organization may start using some sort of orchestration for self-service VM creation by the business units that use VMs. The virtualization team shouldn't have to be involved in every VM build. At this scale, it makes sense to have some build automation for your virtualization hosts. Rebuilding and keeping dozens of hosts up to date is a lot of work. You probably still want a person involved in each host build, although they won't type the commands; they will simply make sure the host is built right. You also probably don't need to automate the checking of the automation, but you may augment the health checks and backup scripts with compliance and configuration checks that run automatically and are manually reviewed.
Enterprise and cloud scale: Automate or fail
In an environment with hundreds of virtualization hosts and thousands of VMs, you'd better have everything automated or your costs will spiral completely out of control. Your staff must not be involved in making VMs for customers and needs to have automation of the host-provisioning process with the automated checking of the host build's success. At this scale, even storage provisioning needs to be automated, and all of the automation has to have automatic checks to verify that it worked as expected. You may even need to automate the procurement process, making sure physical resources are delivered in time to meet demand. This is where simple automation isn't enough and workflow automation is needed. You don't really want a script to raise a purchase order for a new storage area network or a rack full of servers without human checking, but you do want the process to start automatically if there is an impending shortage of either resource.
Automation is different at each scale and for each organization. The mantra of "automate all the things" needs to be overlaid with an understanding of the costs and benefits of automation. Wherever you have a scripted process, make sure the team knows what script to use for which purpose and how to update the scripts when the environment changes. The only thing worse than not automating is trying to automate too much.