5¢ on YAML in the DevOps world

YAML Fatigue is Real: Are We Forgetting the “Why” Behind Declarative Config?

Lately, it feels like everywhere you look, there’s a YAML wrapper.

Often, a simple envsubst would suffice. I see many apps and frameworks that – let’s be honest – often just feel like a slightly polished YAML layer over a simple API call. And then there are the countless YAML-based Task Runner projects that are trying so hard to be the next-gen CI configuration (taskctl?… 😬).

It makes you wonder: did we collectively miss the memo on convention over configuration? And the deeper question: why did we go down the declarative path (Hello, CloudFormation!) instead of sticking with plain imperative scripts?

Sometimes, these solutions look less like elegant abstractions and more like… a new generation of thinly layered YAML wrappers. It’s the new micro-project for the CV, replacing the old, “unfashionable” NPM one. Am I right?

The Usability Tightrope

Of course, I get the underlying goal: making things easier to grasp and use. We want to lower the barrier to entry, and a well-designed YAML configuration can do that beautifully.

But that’s where the rubber meets the road.

You often hit the limits of these “simple” solutions and suddenly find yourself writing some truly odd workarounds. You realize that the trade-off for simplicity is often a lack of expressive power, and you have to break the declarative model to get the job done.

So, the central tension remains: who is going to build the most usable abstraction? The one that gives us enough power without drowning us in configuration files that are just as complex as the scripts they replaced?

The Declarative vs Imperative Infrastructure-as-Code Discussion Is Flawed

Yep. It is. For a deep dive into this, I highly recommend this article:

The Declarative vs Imperative Infrastructure-as-Code Discussion Is Flawed