High Functioning Laziness
Preamble
I'll admit: I'm lazy.
Not lazy as in “I don't want to do this”, but lazy as in “I don't want to manually do this”. There's a big distinction. I'll happily spend multiple hours automating a five minute task if it means that I'll never have to manually perform that task ever again. There are a couple of reasons why I chose to go this route:
If it's worth doing at all, it's worth automating. Me
Manual work leads to errors
Humans are incredibly clever, and incredibly stupid at the same time. Whenever humans get involved small errors get introduced left and right. Some of them you'll never notice, others might bring down an entire site. Removing humans from work that can be automated means removing those errors. A script or playbook will always perform every step as written.
Automating something makes you understand it
When writing automation scripts for a task you have to truly understand the task, and the tools it uses. This includes, if you're doing it right, every possible failure state. This in turn leads to a more robust environment.
You gain more time to work on what matters
Automating things takes time, but in the long run it saves time. All those five minute (or longer) tasks you would otherwise have to run daily or weekly are suddenly gone, freeing up time for more important tasks.
Total failure recovery becomes easier
When you have a lot of snowflakes in your environment, recovering from a catastrophic failure like total storage loss becomes a lot harder. If everything, including deployments, is automated, it only means running the deployer script/tasks/playbook/manifest/whatever again. Of course you still have to restore data, but that can be automated as well.
Spinning up test environments becomes a whole lot easier
Just run the automation script passing in a different environment name, done.
Implementation
This is actually the hard part. It takes proper dedication to being lazy to not just do a small, one-of, task by hand when it pops up. Apart from that you will also need to configure your automation framework, and write your scripts. All of this takes time, but it will be time well spent. Remember that that one small task will probably come back later (in a slightly modified form). Writing the automation now means not having to deal with it later. Future-you will tank you.
Choosing your tools
Choosing the correct tools for the job can be daunting, there are a lot of tools out there that can help. My advice: pick one and stick with it for (mostly) everything. If you mainly do Ops type work that means something like Ansible, Puppet, SaltStack, or Chef. If you mainly do Dev work it can be any of the above, or a pipeline management tool like Jenkins, Bamboo, or Travis CI.
Sticking with it
So you've got your tools selected. Installed everything, and are now busy moving all your workflows into automated pieces of magic. Now someone shows up at your desk to request a small, inconsequential, change to a project somewhere. Since it's just a small changec your instinct might be to just manually make that change and be done with it, thirty second job. One problem, your running environment is now different from what you've got neatly stowed away in your configuration management files in git. From here two things can happen:
- You have to deploy a new environment, and it's no longer the same as the previous.
- You make a proper update to your environment and the change you just made disappeared.
Neither of those sounds appealing. Once you start managing your environment in an automated way, you will have to do everything that way. It might sound like a downside at first, but in the long run it does pay off.