The problem - (its people) #
Raise your hand if you’ve seen this before, you have a workload in Azure that is managed by code, you have to rebuild it, move it to another location or deploy it to a higher environment and it simply doesn’t work.
Why?
Because Tom from the application team made a crucial change to the application infrastructure using the portal.
And then forgot all about it.
This is called drift, and although you can use various tools to identify drift with the most commonly used Infrastructure as Code (IaC) tools - terraform/OpenTofu has the plan capability, ARM/Bicep has what-if commands, they both have the same obstacle. You only know when you’re actively checking for drift, and they also don’t tell you who made the drifting change so you can train people after the fact.
ClickOps versus GitOps #
Before we dive into the specifics of ClickOps, its important to know about the polarity term; GitOps. GitOps is the nirvana when it comes to a fully operational and stable infrastructure.
- Everything is coded and automated - if it isn’t in the repository; it doesn’t exist.
- Changes can be backtracked back to the code changes, so if something breaks - git is there to help you, or in a cloud infrastructure; at the very least
These changes are also known as “ClickOps”, the polarity term of the GitOps and are most commonly born out of
There are two approaches to reducing ClickOps, Detection & Prevention or Identify & Up-skill.
