What the author appears to miss is that many existing IAC tools permit exactly this.
CDK, CDKTF and Pulumi all use general purpose programming languages, so reusing parameter objects in the way that is described is trivial - indeed it is so close to second nature that I would not even think to write it down. Indeed, it's not uncommon to share functions that make such parameter objects via libraries in the package ecosystem of your choice.
I agree that IaC needs a rethink, but that is more to do with the fact that declarative systems simply cannot model the facts on the ground without being substantially more complex.
I'm the author of the article. I actually shared a prototype towards the end of the article, of the idea implemented in CDK. I agree that you can do a lot of this already in CDK, CDKTF, and Pulumi. I just don't think most people are actually doing it (yet).
I've been using CDK since early beta, and have actively contributed to the project. But most people that I'm seeing using it today are just wrapping up new higher abstractions with a simpler but limited API. I think that is an okay start, but I want to encourage people to think more about the infrastructure as being made up of traits/classes/adjectives that are mixed together to form the final product. The same way we have class inheritance in object oriented programming, or CSS classes in HTML.
Eventually the dream is to be able to provide a library of standard infrastructure as code mix-ins that can be applied to your cloud architecture. For example imagine if you could apply a generic "Graviton" trait to a CloudFormation or Terraform or Pulumi or CDK stack and it would automatically configure the appropriate properties on your EC2 instances, and your RDS database, and your Fargate tasks, and all your other compute. With CDK's built-in container and image builds it could even run your Dockerfile based build inside of the matching architecture as well, all based on a single trait that you add to your stack.
There are a wide variety of these types of "traits" that you might be able to build and add.
Most people are still clicking around the console. A new paradigm is not required to allow them to use what already exists, just education.
The question of WHY the mixins are required is interesting to me - they point to the abject failure of cloud providers to keep up with their customers.
As I work at a cloud provider I have a different perspective on the mix-ins. The problem is that at scale there is no one customer type. Some customers absolutely require a specific way of configuring things, while other customers require exactly the opposite. Cloud providers are always trying to add more features to please all people, its a fundamental side effect of growth. And an often unstated aspect is that the most custom features are often extremely high value ones that were added for customers that worth large amounts of money to the business, even though the other 90% of small users and startups may not need that.
I think mix-ins can be a way to make the growth in features accessible while not overwhelming. Out of the box mix-ins can provide 80% of the value for 80% of the people and the long tail of 20% customers with the super custom needs that are worth high dollar amounts can still build their own custom mix-ins that target their specific use cases.
Adding a "real" programming language makes certain things easier, such as abstraction, but IMO they are too powerful for the task at hand. Do we really want an infrastructure description to be able to execute arbitrary code?
Yes, that’s exactly what we want. Things like Terraform also permit this via provisioners, and CloudFormation permits it via execution of lambda functions. Almost any non trivial infrastructure requires it.
With Terraform you can statically analyze the infrastructure definition with some guarantees of determinism etc. Arbitrary execution is allowed, as you say, but only in well-contained places, such as local_exec.
How can this work if, say, TypeScript is used as the definition language?
CDK, CDKTF and Pulumi all use general purpose programming languages, so reusing parameter objects in the way that is described is trivial - indeed it is so close to second nature that I would not even think to write it down. Indeed, it's not uncommon to share functions that make such parameter objects via libraries in the package ecosystem of your choice.
I agree that IaC needs a rethink, but that is more to do with the fact that declarative systems simply cannot model the facts on the ground without being substantially more complex.