December 14, 2023

Click Ops Is A Recipe For Disaster

Click-Ops

Developer operations performed by clicking through a cloud providers UI and manually entering data

Anyone who has used AWS, GCP, or any other cloud provider knows the massive amount of configuration that goes into setting up resources in these environments. Most major cloud providers provide a web-based user interface on-top of cloud resources for configuration.

These consoles can be great tools for learning to use these services, but often become a hinderance to work in more complex environments. Here’s a list of reasons to kick your click ops habits:

You ARE going to do that more than once

Without fail, one of the go-to excuses for performing Click-Ops actions within a cloud provider is:

“Writing a script will take more time, I’m only going to do this once!”

I would challenge that assumption. In most engineering environments, it’s reasonable to expect that any action performed in a production environment would first need testing in a non-production environment. Assuming that you are performing work that will eventually need to exist in prod, you can help yourself by automating the process and ensuring the actions performed are identical across environments.

Additionally, the biggest contributor to my understanding of IaC scripting and configuration was requiring myself to write scripts.

Your cloud provider’s configuration set is bigger than human working memory

Human working memory is a concept that models the ability of the human brain to store information temporarily. If you are memorizing AWS configuration variable temporarily, you are using working memory. This poses the following problems:

Working memory is limited in size (most untrained individuals can consistently memorize 7-12 items before becoming inconsistent)
Very few AWS components have less than 12 configuration properties
Moving from working memory to long-term memory is not easy

AWS CLI docs for route53 commands — There aren't a whole lot of easy-to-use mnemonic devices to memorize all this

Pure text configuration is easier to read and validate

Cloud-provider UIs are not designed for collaborative work. The only way to properly validate a configuration with another engineer from a cloud provider user interface is to share a screen with another developer. Written scripts create a written, auditable, verifiable record of the actions that were taken.

This:

resource "aws_route53_record" "www" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "www.example.com"
  type    = "A"
  ttl     = 300
  records = [aws_e

Will always be easier to parse than this:

Slack message showing a developer asking to call for validation of aws config — Can you see my screen?

You’ll be surprised how often they come in handy

I maintain a list of scripts that I frequently use in my day-to-day tasks at work. When I first started retaining these scripts, I didn’t realize how often I was doing certain tasks. I was pleasantly surprised every time I thought I had to perform a time-consuming task manually, only to remember I had scripted it out previously