| Actually, I think it's not going backwards, but moving in circles, with some changes, hopefully improvements, each time through the loop, so possibly a bit like a corkscrew in 3D. (circles in two dimensions, straight line in third dimension). Why are we going in circles? Because there are conflicting requirements and our implicit assumptions prevent us from resolving the conflict. The conflicting requirements are being able to describe infrastructure in its own terms ("declaratively"), the other is being able to abstract over infrastructure. If the first requirement is prioritised, we get JSON files, yaml files or specialised IaC DSLs that tend to be limited, partly on purpose, but mostly accidentally, to the point of being crippled. We soon discover the limitations of this approach, which is essentially that for anything a bit more complex we need the abstraction capabilities of a general purpose programming language. Martin Fowler makes a very similar case for integration here: https://martinfowler.com/articles/cant-buy-integration.html So the pendulum swings towards general purpose languages with "infrastructure libraries". As far as I can tell, we've had two broad generations of these: the first was libraries to build the infrastructure, the second that we are on now (CDK, Pulumi) output "declarative" descriptions of the infrastructure. Sounds good, except that there is now a layer of indirection, because essentially all our general purpose languages are actually not general purpose, they are domain specific languages for the domain of algorithms. So what you can express is an algorithm for creating the infrastructure(-description), not the infrastructure(-description) itself. That doesn't sound like a big deal, but it actually is, not least because the indirection encourages all sorts of shenanigans and messes, including overdosing on indirection. I think the only way to break out of this back-and-forth (or circle) is to create general purpose languages that can directly express and abstract over things other than algorithms. Oh, and there's actually a third somewhat conflicting requirement: this description needs to be accessible programmatically (see Kubernetes and friends). If it's true, as I believe, that the other requirements point to a specific linguistic solution, this means that there also must be really great metaprogramming APIs. Objective-S (http://objective.st) has those capabilities, and recently I've been starting to do some experiments with describing and acting on infrastructure, and the early results have been very promising. Having the concept of URI built into the language (Polymorphic Identifiers) is a good start for directly talking about infrastructure. Storage Combinators also help a lot and the software-architectural concept of a "system" composed of components connected via connectors also seems to map in a fairly straightforward manner. |