The problem with most black-box declarative interfaces is that you often do care about how things will happen. The real-world limitations often leak through the declarative interface, because you have to care about things like performance, or do things that don't quite fit into the opinionated declarative interface, or have other weird constraints that the authors didn't think of.

And then you're in a world of pain, where you have to not only know how to do what you want, but then also how the system will map from declarative->imperative, and then how to massage your declarative input so that it does the right imperative thing. And your teammates too. And you've all got to think about it every time you change the code or upgrade.

I've run into this problem in nearly every declarative system I've ever used (examples: SQL, Prometheus, infrastructure-as-code frameworks, dependency injection frameworks, ORMs, k8s, and so on).

Neither approach is "better". They have tradeoffs.

> The real-world limitations often leak through the declarative interface, because you have to care about things like performance, or do things that don't quite fit into the opinionated declarative interface, or have other weird constraints that the authors didn't think of.

But this is the case with opinionated imperative interfaces as well. It's irrelevant to the declarative vs imperative issue. This is a fundamental aspect of abstractions. There will always be things you can't do unless you're writing assembly on bare metal. And even then, assembly is an abstraction over microcode, and what the actual hardware is doing.

Any API can have issues, but an imperative api has some advantages in my opinion.

The boundaries of an imperative api are atomic and easily well-defined. When something goes wrong, it is possible to look at the methods individually and figure out exactly where expectations and reality diverged.

With a declarative system you just put out everything there as one big chunk of state and hope the right thing happens. When the wrong thing happens, it's usually not clear if the problem is a bug with the engine or your understanding of it, and also not clear how to go about determining where the problem is.

To be clear, I am not totally against declarative systems, but I would be hesitant to use any declarative system if it isn't mature and well-tested, documented with priority, and in a space where the use cases are predictable.

I think it gets worse as an interface gets more declarative and tries harder to hide machinery and state (or tries less to expose it), either on principle or because it allows for extra safety or optimizations or evolution.

Probably the sweet spot is declarative with an imperative escape hatch.

The vast majority of time, you just want your SQL query to give you back the right rows and don't care how the DB engine manages it. In the rare case where it takes too long, then you want to be able to dig into the query plan, change the indexes, maybe even deploy a custom function written in a different language in extreme cases.

Both React and Webpack could be considered hybrid declarative/imperative approaches and have been very successful in the FE ecosystem

> The problem with most black-box declarative interfaces is that you often do care about how things will happen. The real-world limitations often leak through the declarative interface, because you have to care about things like performance, or do things that don't quite fit into the opinionated declarative interface, or have other weird constraints that the authors didn't think of.

Can you give an example of this for k8s?

> Can you give an example of this for k8s?

Deployment.spec.strategy is a common purely "how" configuration switch.

Explicit PodDisruptionBudget is less common but exists only to configure a "how". A smarter (e.g. layer 6+ aware) system should be able to derive this for me.

You might respond "well, that's what an operator is for" and in some sense you're correct, but every operator I've read is a mess of the most imperative code I've ever seen; and then that leaks out as soon as the operator's defaults don't work well for your case.

As someone who has spent the last 7-8 years working on declarative infrastructure tooling: this is only better if the tool can work out how to get from where things are to where you want them to be without being destructive. It’s not like these tools are composing pure functions, sadly.

> this is only better if the tool can work out how to get from where things are to where you want them to be

That's a bit like sating car is only better than a horse if the engine works. The tool has one job,

They do ofcourse fail regularly, I feel that devops tools are 10 years behind our development tooling

Part of the reason they fail so regularly is because so many are wedded to the declarative model, in order that they don't have to understand what they are managing and how it operates.

Except that with k8s, it's somewhat declarative. A number of things are immutable, or they're mutable, but will never be picked up if they change. So, you have to jump through hoops in those spots to make things declarative, like ensure things have unique names (like config maps with mounts that have sub keys), and orchestrate pod restarts. Kustomize/argo will do this orchestration for you, in a way that makes your config look like it's declarative.

Also, you really do need to know how things are going to change when they're changed. By default when you update your deployments in k8s, you're probably going to have a brief amount of downtime. Argo rollouts and such let you define this declaratively, in a way that avoids downtime, but again, more complexity.