ClickOps is an Anti-pattern

Photo by Sigmund on Unsplash

Infrastructure as Code (IaC) is touted as an industry-wide best practice, but why is the alternative called ClickOps, and what are its pain points?

What is ClickOps?

ClickOps is the error-prone and time-consuming process of having people click-through various menu options in cloud providers’ websites, to select and configure the correct automated computing infrastructure. ¹

When you are first learning about a new technology having a UI to assist you in making changes can be invaluable. Services like AWS, Azure and Google Cloud Platform provide “self-guided” paths to help you provide their services. However, continual reliance on the UI is an anti-pattern that can introduce many problems, including:

1. Error-prone: human beings are notoriously bad at completing a series of tasks without making at least one error.
2. Inefficient: clicking through a web UI is much slower than automation, not to mention the cognitive penalty you need to pay when this type of task needs to be completed infrequently. The user needs to re-learn the steps every time.
3. Lack of Audit Trail: changes are either not tracked in an audit trail or very hard to find. In contrast, IaC will track changes to the configuration in a source code control system.
4. State Drift: Using the web console, a user may accidentally update your infrastructure in a way that is not tracked, potentially disabling your ability to manage your infrastructure programmatically. See CloudFormation Drift Detection.
5. Lack of Transparency: without having a source of truth checked into source control, developers will be dependent on admin-level users to keep everyone up to date with the system’s configuration.

What’s the alternative?

Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. ²

Often referred to as determinism or ‘deterministic deployment’ IaC allows developers to define their infrastructure dependencies for their software in the same way we define software dependencies in lockfiles. Code is versioned in Git right beside the infrastructure dependencies ensuring that the deployment artifact has all the necessary cloud resources the code depends on. Everyone contributing to the software can recreate the environment identically every time.

There are many options for IaC. There are third-party tools like Terraform and Pulimi and there are cloud-native options AWS CloudFormation or Azure Bicep. Some folks prefer imperative languages for IaC. Some folks prefer declarative languages.

It is our opinion that if the job is in service of reliability and determinism that declarative languages are a better solution, imagine if package.json was package.js…no thanks! But to each their own. We also prefer the reliability of first-party cloud-native solution CloudFormation at Begin but find it verbose and difficult to author so we created the terse high-level format app.arc which compiles down to CloudFormation.

The Future of IaC

In a recent post, ClickOps, Corey Quinn posits that the future of ClickOps will record the changes in the UI, generate the diffs, and commit to the IaC repository giving you the best for both worlds.

For now, at Begin and in the Architect open source project, we will continue to use the app.arc project manifest file to unlock the complex tasks of cloud infrastructure provisioning, deterministic deployment, and orchestration.