Fast today, expensive tomorrow
Opening the provider's console, creating a machine, opening a port and adjusting a size takes five minutes. That is why almost every infrastructure starts that way. The problem does not appear that day, but months later, when simple questions have to be answered:
- Why is this port open?
- Who changed the size of this database?
- Why does acceptance not behave like production?
The console records that something changed, at best. It does not record why, it does not let you review it beforehand and it does not help you repeat it somewhere else.
How environments drift apart
The most damaging effect of clicks is silent: drift between environments. Somebody expands a disk in production because of an emergency and does not do it in acceptance. Another person opens a port in development to test something and leaves it. A third updates a version only where they needed it.
Each change, in isolation, is reasonable. Together, they produce environments that no longer resemble each other, and an acceptance environment that stops being any use for predicting production (as we saw in the Platform series).
This is not about banning the console either
The console remains useful for looking: exploring, diagnosing, understanding what is going on. The change of habit is a different one: the console is for reading; changes are made in code. And if an emergency forces a change by hand, the change is taken into the code that same day, so that reality and its description do not part company.
For that rule to be easy to follow, the code has to describe what you want, not the list of steps to get there. That is the difference between declaring and ordering.
How we apply it: Automation and IaC.