ClickOps

How it works

ClickOps is the practice of creating and changing cloud infrastructure by hand through a provider’s web console, instead of defining it in code. Examples include creating a virtual network, database or load balancer by clicking through the AWS Management Console or the Azure portal.

It is how many teams begin, because the console is visual, immediate and needs no extra tooling. The result, however, exists only as live resources and in people’s memory. There is no reviewable record of what was configured, who changed it and why, apart from whatever audit logs the provider offers.

The alternative is Infrastructure as Code (IaC): describing resources in files that live in version control, are reviewed like application code, and are applied by a tool such as Terraform. Changes then become pull requests with a history.

A practical example

A team built production by hand two years ago. Staging was built later from memory and now differs in several settings. To move to code, they can inventory what exists, write Terraform for one component, and use terraform import to attach the existing resource to the new configuration without recreating it. Running terraform plan should then show no changes. Any differences it shows are drift between the code and reality, which the team resolves deliberately, one component at a time.

Common mistakes

• Making emergency console changes and never recording them, so code and reality diverge.
• Importing everything at once instead of migrating in small, verified steps.
• Writing code that imports resources but is not reviewed, which only moves the problem.
• Leaving console write access open to everyone after IaC is adopted, so manual changes continue.
• Skipping a resource inventory first, so forgotten resources and costs go unnoticed.
• Assuming that screenshots or wiki pages are an adequate record of configuration.

When to use it and when not to

The console is fine for learning, exploring a new service and one off investigation. It is a poor basis for anything that must be repeatable: production environments, multiple environments that should match, or anything you might need to rebuild after an incident. A sensible rule is to explore in the console, then codify what you keep. Restricting console write access once code is in place helps stop drift.

Our ClickOps to Terraform and ClickOps cloud setup pages describe how we approach migration.

See also

• Infrastructure as Code
• Terraform