Vendor support shapes how we learn IaC

19 Nov 2025 🔖 devops
💬 EN

Hot take / shower thought:  for any given IT resource configurator/administrator, the ease of grasping the point of idempotently declarative approaches to managing the current state of the resource’s configuration is largely dependent upon their good/bad luck with vendor support.  Vendors set the tone for learning journeys.

First everyone said no flat files

Computer science spent decades trying to create databases that were “more optimized” for data storage/retrieval/processing than flat files were.

Then Git so actually yes flat files

And then … like … we wanna go throw that all away and go back to storing our desired resource configuration in flat-files (that is, git repositories)?!

And yes, the answer is yes.  There are a lot of great arguments for doing so:

1. Configuration data changes at a human scale anyway (by the hour, not by the milisecond); it doesn’t require as much transcation-performance optimization as true “transactional operational data” does.
2. There’s relatively little configuration data, compared to “true transactional data,” so running out of space if you store the data in “inefficient” flat files isn’t a concern.  (Configuration data might be that one accepts payments in USD, CAD.  Whereas the true transactional data is the millions of payments one’s accepted.)
3. The “version history” display of systems designed for helping human brains make sense of changes in flat files are often much easier to understand than, say, combing log tables in a more “optimized” database (that is, if the log tables even exist beyond a certain date; config data-change logging cutoffs might have accidentally gotten caught up in the same trimming that “transactional” data-change logging cutoffs were deliberately subjected to).

Someone has to create a higher-level language

But, like ORM, the desire to use a flat-file-based approach to manage “configuration” depends a lot on whether the vendor support makes doing so a dream or a nightmare.

Lots of cloud-native vendors more or less offered that ORM-like experience from the get-go.  Such vendors quickly put in the work to learn to code in Go and hide the many imperative REST-API-invoking steps required to fake declarative idempotence underneath Terraform providers.  (Or, for some others, at least provide a really robust configuration-data serialization/deserialization schema, so that obscenely complex, compared to Terraform, flat-files can still be version-controlled, even if developers still have to manually invoke a PATCH-based REST API and put a large chunk of serialized desired-configuration data into the body of their HTTP request.  Salesforce “metadata” XML and Sitecore “SCS” YAML/JSON being examples.)

In other words, lots of vendors have, over the 2010s and 2020s, either through IaC-framework libraries, or through robust config-data serialization/deserialization standards, taken the time to author higher-level programming languages (which arguably is all an ORM really is, on top of, say, DDL/DML/SQL).

And we know everyone loves a good higher-level programming language!

Customers shouldn’t have to be that someone

But what if you administer/configure a resource whose vendor doesn’t offer any?

Man, oh man, is it going to be a heavy lift to grasp the point of authoring idempotently declarative flat-files when they … can’t go anywhere unless you also take the time to hand-author your own “compiler” to hide the actual imperative steps that go into faking “declarative idempotent” programming.

Hard to learn what you can’t see

Vendors should define done for declarative read-only validation

• If a vendor gives admins imperative instructions like:

  •   New-Item -Path '.\file.txt' -ItemType 'File'
    

• But if the vendor doesn’t bother to do the work that a trained quality assurance professional would cover, and also instruct that the test case to validate whether or not it actually worked is:

  •   Test-Path -Path '.\file.txt' -PathType 'Leaf'
    

• Then how is an admin ever supposed to easily learn to think declaratively about the definition of “done” for that particular patch?

C’mon, vendors. I beg you: don’t make admins reverse-engineer your imperative patching instructions and guess what an appropriate declarative “definition of done” might be. Vendors – you are the ones who knew what “done” was when you wrote the patch’s instructions. So put that into the instructions, too. Don’t make me think.

Vendors should implement declarative idempotence for write-capable configuration changes

And that’s just a bare minimum of helping developers have at least a prayer of hand-authoring some “declarative read-only validations” that might later support their ability to hand-author enough “if-else” imperative code to run your patch in a way that feels “declarative” and “idempotent” to their colleagues.

(Let’s be honest, making imperative processes seem as if they could run “idempotently” is merely a painstaking process of robustly coding a bunch of if-then-else statements, hidden under the hood of some lower-level abstraction. And making them seem as if they could be defined “declaratively” is merely a painstaking process of robustly coding a bunch of input parameter sanitization and validation, hidden under the hood of some lower-level abstraction.)

I say “merely,” but it’s no small ordeal to get it right, so vendors should be doing it, not leaving it up to ambitious customers. I’m looking at you:

• ITSM helpdesk, CMS, CRM, ERP/general business management, etc. software product vendors that have an imperative REST API for configuration settings but no declarative equivalent.
• Frameworks that turn generic VMs into “something slightly more useful” (e.g. a general-purpose web server, or an event message broker) whose CLI tools still require you to imperatively program them (I see you, IBM MQ, making people author something ridiculous like echo "DISPLAY QLOCAL(queue_name_that_maybe_exists)" | runmqsc queue_manager_name_it_maybe_exists_within instead of just providing a Terraform data provider or Ansible role that can return true/false to an exists).

😡

You’re making my role as a teacher much harder, vendors.

How am I supposed to help resource administrators/configurators deeply grasp all of the benefits that declarative, idempotent IaC allegedly brings to their lives when, thanks to your imperative-only instructions and tooling for them, it doesn’t?

I’ve got nothing relevant to their lives to work with as hands-on training examples!